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Systems  Engineering  for  the  Global  Information  Grid: 
An  Approach  at  the  Enterprise  Level 


Patrick  M.  Kern 

Deputy  to  the  Assistant  Secretary  of  Defense,  Networks  and  Information  Integration! 

Department  of  Defense  Chief  Information  Officer 


Because  the  numerous  United  States  Department  of  Defense  (DoD)  and  Intelligence  Community  (IC)  networks  were  originally 
built  to  serve  many  different  constituencies,  making  the  Global  Information  Grid  (GIG)  a  reality  requires  solving  interoper¬ 
ability  and  performance  issues  at  the  enterprise  level  This  will  be  accomplished  through  the  use  of  systems  engineering  —  a  dis¬ 
cipline  whose  techniques  manage  the  complexity  of  systems  from  abstraction  to  decomposition.  The  GIG  Technical  Foundation 
(GTF)  addresses  a  number  of  systems  engineering  challenges  involvingfocus,  evolution,  coverage,  and  applicability. 


As  you  are  probably  aware,  the  GIG  is  a 
complex,  ongoing  effort  intended  to 
integrate  all  information  systems,  services, 
and  applications  within  the  DoD  and  the  IC 
into  a  seamless,  reliable,  and  secure  network 
that  wfll  support  horizontal  information  flow 
and  net-centric  warfare. 

The  GIG  represents  a  different  way  of 
thinking  about  delivering  capabilities,  a  way 
of  thinking  that  can  cope  with  the  uncertain¬ 
ties  we  face  in  the  world  today.  In  the  past, 
missions  focused  on  narrow  objectives 
against  known  adversaries  and  were  orga¬ 
nized  with  tightly  managed  organizational 
responsibilities  across  the  DoD  and  IC  con¬ 
stituencies.  Today,  adversaries  are  shadowy 
and  shifting,  objectives  are  far-reaching,  and 
new  responsibilities  link  our  organizations  at 
all  levels.  The  DoD  and  IC  networks  built  in 
the  past  evolved  into  stovepipes,  tied  to  mis¬ 
sions  and  organizations  that  now  are  forced 
to  adapt  to  a  more  fluid  world.  The  GIG 
confronts  uncertainty,  inherent  in  today’s 
world,  with  the  agility  that  comes  from  inter¬ 
connected,  interoperable  solutions  that  can 
be  tailored  to  today’s  missions  and  objectives. 
Making  the  GIG  a  reality  requires  breaking 
out  of  stovepipes  and  solving  interoperabili¬ 
ty  and  performance  issues  at  the  enterprise 
level.  We  have  approached  the  problem  of 
building,  populating,  operating,  and  protect¬ 
ing  the  GIG  by  applying  systems  engineering 
discipline  to  the  complex  set  of  communica¬ 
tions  systems,  information  systems,  services, 
and  applications  that  make  up  the  GIG. 
Systems  engineering  as  a  discipline  provides 
us  with  the  techniques  to  manage  the  com¬ 
plexity  of  systems. 

Enterprise-Wide  Systems  Engineering 
(EWSE),  as  appltyng  systems  engineering  to 
the  GIG  at  this  level  is  known,  can  only  suc¬ 
ceed  by  properly  focusing  the  effort.  EWSE 
utilizes  interoperability  and  end-to-end  per¬ 
formance  as  the  criteria  to  determine  what  is 
within  scope.  Enterprise  decisions  for  these 
requirements  are  then  documented  and 
enforced  in  the  design  of  GIG  component 
systems,  laying  the  groundwork  for  the  GTE 


The  GTF  is  the  configuration-managed,  syn¬ 
chronized  set  of  all  authoritative  technical 
guidance  required  for  planning,  developing, 
acquiring,  and  implementing  an  interoperable 
and  secure  GIG. 

Background 

With  origins  in  a  wide  range  of  component 
systems  procured  to  support  autonomous 
agencies  and  services,  the  GIG  is  more  accu¬ 
rately  an  organizing  construct  than  an  actual 
system.  Its  legacy  components  vary  in  terms 
of  performance,  storage,  and  process,  and 
they  must  continue  to  support  their  existing 
user  communities  even  as  they  become  part 
of  the  GIG.  While  many  individual  compo¬ 
nent  systems  are  unknown  at  the  enterprise 
level,  the  GIG’s  component  set  -  as  well  as 
the  components  themselves  —  will  evolve  to 
reflect  participant  groups’  capabilities  and 
financial  priorities.  The  challenge  is  to  estab¬ 
lish  a  process  that  brings  these  disparate 
components  together  into  a  single  entity  that 
meets  the  needs  of  all  users. 

As  GIG  component  systems  are 
designed,  built,  and  funded  by  member  orga¬ 
nizations,  it  is  necessary  to  deductively  estab¬ 
lish  the  functions,  protocols,  and  data  models 
required  for  their  interoperability  and  perfor¬ 
mance.  Such  an  investment  will  benefit  all 
GIG  users. 

Scope  of  the  Effort 

The  Assistant  Secretary  of  Defense,  Net¬ 
works  and  Information  Integration 
(OASD[NII]/DoD  Chief  Information 
Officer)  tasked  the  Defense  Information 
Systems  Agency  to  lead  an  Enterprise 
Documentation  Framework  Working  Group 
that  would  apply  systems  engineering  prac¬ 
tices  to  create  the  GTF.  The  GTF  provides 
structure  and  traceability  for  all  GIG  docu¬ 
mentation  in  a  manner  similar  to  that  of  a 
document  tree.  The  GTF  is  based  on  and 
traceable  to  operational  needs  derived  from 
national  and  DoD  strategic  guidance  and 
direction.  It  includes  enterprise-level  GIG 
documentation  (GIG  capabilities;  activities; 
technical  requirements,  including  standards 


and  specifications;  and  the  GIG  Architec¬ 
ture)  and  other  GIG-related  technical  docu¬ 
mentation’. 

Applying  systems  engineering  at  the 
enterprise  level  to  support  development  of 
the  GTF  must  start  with  the  GIG’s  vision  as 
outlined  in  the  Net-Centric  Operations 
Environment  Joint  Capability  Documenfi. 
Once  top-level  requirements  are  defined  to 
identify  the  necessary  functionality,  this  func¬ 
tionality  can  be  decomposed  into  system  seg¬ 
ments  and  sub-segments. 

Top-level  requirements  have  been 
decomposed  into  three  areas  -  general,  enter¬ 
prise  management,  and  Information 
Assurance  —  and  flow  down  to  requirements 
at  the  segment  level.  These  segments  include 
transport,  services,  applications,  computing 
infrastructure,  and  enterprise  operations. 

Segment  and  sub-segment  requirements 
are  specified  as  needed  for  interoperability 
and  performance  according  to  the  top-level 
requirements,  which  can  be  traced  from  GIG 
capabilities  and  requirements  to  segment  and 
sub-segment  requirements.  Sub-segment 
requirements,  needed  to  achieve  interoper¬ 
ability  and  end-to-end  performance,  are 
often  the  specification  of  protocols  or  mech¬ 
anisms. 

Figure  I  illustrates  the  relationship 
between  top-level  requirements,  segment- 
level  requirements,  and  sub-segment  require¬ 
ments  for  a  transport  segment  example. 

Systems  Engineering  Challenges 

In  addition  to  scope,  the  GTF  addresses  a 
number  of  systems  engineering  challenges 
involving  the  foilowing: 

•  Focus.  AH  requirements  for  achieving 
the  GIG  capabilities  -  including  what  is 
currently  feasible  and  what  requires  fur¬ 
ther  development  -  must  be  specified  by 
the  GTF  to  ensure  that  programs  under¬ 
stand  the  needed  transitions.  Programs, 
services,  and  agencies  responsible  for 
existing  GIG  component  systems  are 
then  responsible  for  developing  transi¬ 
tion  plans  that  reflect  the  requirements  of 
the  GTF. 
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Sub-Segment-Level  Requirements  (Current  and  Maturing) 

Figure  1 :  Transport  Segment  Tixample  Illustrating  the  Relationshp  Between  Requirements 


•  Evolution.  Many  aspects  of  the  GIG’s 
long-term  vision,  including  pervasive 
mobility,  ad-hoc  network  connection, 
efficient  resource  use,  and  dynamic 
resource  allocation/management  are  not 
achievable  through  use  of  current  tech¬ 
nologies.  Long-term  GIG  design  must 
not  be  limited  to  requirements  dependent 
on  current  technology,  but  include  provi¬ 
sions  for  emerging  and  future  technolo¬ 
gies  as  well. 

•  Coverage.  As  mentioned  earlier,  the 
GIG  is  made  up  of  a  wide  variety  of 
components,  many  of  which  are 
unknown  at  the  enterprise  level. 
Components  will  be  added  and  removed 
as  organizational  needs  evolve,  and  the 
components  themselves  will  also  evolve. 
As  a  result,  requirements  for  the  GIG 
must  be  specified  in  terms  of  component 
type  rather  than  for  specific  components. 
Requirements  must  also  be  defined  for 
the  set  of  systems  needed  to  meet  GIG 
capabilities  rather  than  for  those  appro¬ 
priate  only  for  existing/ planned  systems. 

•  Applicability.  Since  GIG  users  will 
operate  in  a  variety  of  environments, 
requirements  need  not  apply  to  all  envi¬ 
ronments  or  modes.  Specific  domains  of 
applicability  must  be  defined  which  work 
in  concert  to  provide  overall  enterprise 
capabilities.  For  example,  fixed  users  are 
well  connected  and  can  reliably  reach 
centralized  data  centers.  The  fixed  users 
are  not  severely  constrained  in  power, 
memory,  storage,  and  processing. 
Examples  of  fixed  user  modes  are  camps, 
posts,  stations,  and  bases  served  by  the 
Defense  Information  System  Network. 
Advantaged  tactical  users  operate  in  a 
slowly  changing  environment  subject  to 
high  latency  and  limitations  on  band¬ 
width  that  may  constrain  reach-back  to 
centralized  data  centers.  The  advantaged 
tactical  users  are  not  severely  constrained 
in  power,  memory,  storage,  and  process¬ 
ing.  Examples  of  advantaged  tactical  user 
modes  are  tactical  operations  centers  and 
Navy  ships.  Disadvantaged  tactical  users 
operate  in  a  highly  dynamic  topology, 
with  limited  and  sometimes  no  fixed 
infrastructure,  subject  to  disruption  in 
communications  and  with  severe  con¬ 
straints  on  one  or  more  of  power,  mem¬ 
ory,  storage,  and  processing.  An  example 
of  disadvantaged  tactical  user  mode  is  a 
Mobile  Ad-Hoc  Network  formed  by 
vehicles  and  dismounted  soldiers. 

Assembling  the  GTF 

The  GTF  is  intended  to  address  aU  require¬ 
ments  relating  to  the  GIG’s  long-term 

vision,  even  those  not  achievable  through 

the  use  of  currently  available  technologies. 


protocols,  and  mechanisms.  Sub-segment 
requirements  are  divided  into  two  categories 
—  current  requirements,  which  are  achievable 
using  current  technology,  and  maturing 
requirements,  which  rely  on  emerging  and 
future  technologies. 

Current  requirements  are  testable  and 
win  be  enforced  in  the  design  of  GIG  com¬ 
ponent  systems.  By  contrast,  maturing 
requirements  are  used  to  document  tech¬ 


nologies  needed  to  achieve  GIG  capabilities, 
verify  the  feasibility  of  achieving  GIG  capa¬ 
bilities  and  provide  insight  on  research  need¬ 
ed  to  meet  the  GIG  vision. 

Occasionally,  use  of  a  technology,  mech¬ 
anism,  or  protocol  that  does  not  satisfy  GIG 
requirements  is  sanctioned  if  no  other 
resource  is  available.  In  these  instances,  a  cur¬ 
rent  requirement  is  defined  for  the  existing 
technology,  and  a  maturing  requirement  is 


Figure  2:  Trocess  for  Assessing  Technologies  for  Inclusion  in  the  GTF 
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defined  for  the  needed  technology.  For 
example,  inter-domain  routing  today  would 
use  border  gateway  protocol  version  4  as  a 
current  requirement.  A  new  protocol  to  sup¬ 
port  pervasive  mobility  is  defined  as  a  matur¬ 
ing  requirement. 

At  all  phases  of  the  process  of  assem¬ 
bling  the  GTF,  stakeholders  and  subject  mat¬ 
ter  experts  participate  in  working  groups  to 
assess  technologies  and  determine  the  appro¬ 
priate  match  for  current  and  maturing 
requirements.  Figure  2  (see  page  11)  illus¬ 
trates  the  process  used  to  assess  technologies 
for  inclusion  in  the  GTF. 

Community  Role  in  GTF 
Development 

Before  the  establishment  of  the  GTF,  differ¬ 
ent  organizations  attempted  to  define  the 
GIG  in  separately  developed  technical,  pok¬ 
ey,  and  guidance  documents.  This  resulted  in 
more  than  7,000  pages  of  documentation, 
which,  although  wek  written,  contained  gaps, 
overlaps,  and  inconsistencies  that  reflected 
the  GIG’s  fragmented  origins  in  component 
systems  originally  intended  to  function  inde¬ 
pendently.  Once  it  was  realized  that  the 
emerging  GIG  documentation  did  not  have 
the  technical  maturity  to  meet  end-to-end 
interoperabkity  and  performance  compKance 
standards,  members  of  the  GIG  user  com¬ 
munity  began  to  develop  baselines  against 
which  its  individual  components  could  be 
measured. 

Today’s  GTF  is  a  set  of  source  docu¬ 
ments  drawn  across  the  GIG  community, 
along  with  governing  statements  for  GIG 
development,  providing  portfoKo  and  pro¬ 
gram  managers  with  clear  guidance  on  how 
to  implement  net-centricity  and  end-to-end 
interoperabkity  throughout  the  acquisition 
Kfe  cycle.  It  includes  authoritative  source  doc¬ 
uments  that  define  the  strategic  guidance, 
operational  context,  operational  capabikties. 


GIG  capabikties,  GIG  activities,  and  techni¬ 
cal  direction  needed  to  take  the  GIG  through 
the  fokowing  timeframes;  near  (0-2  years), 
mid  (3-7  years),  and  far  (8+  years). 

The  GTF  also  contains  governing  state¬ 
ments  extracted  from  these  source  docu¬ 
ments  that  more  concisely  describe  the 
GIG  and  are  traceable  throughout  the 
GIG’s  Enterprise  Document  Framework. 
AU  content  is  stored  and  managed  in  a 
DOORS’  requirements  database  to  facki- 
tate  requirements  management  and  config¬ 
uration  control. 

Compliance 

By  developing  this  integrated  approach  to 
compkance  assessment  that  akgns  current 
processes  and  provides  an  entry  point  to  the 
Net-Ready  Key  Performance  Parameter  evo¬ 
lution,  the  GTF  does  the  following: 

•  Akows  program  managers  to  self-assess 
individual  programs. 

•  Appkes  consistently  to  ak  programs  at  ak 
levels  of  oversight. 

•  Ensures  high  confidence  in  end-to-end 
interoperabkity  and  performance  compk¬ 
ance  at  the  enterprise  level. 

Pokey  has  also  been  revised  to  direct  ak  com¬ 
pkance  to  the  GTF. 

Conclusion 

The  GIG  is  an  ambitious  undertaking  that  is 
fundamental  to  net-centric  warfare.  We  have 
estabkshed  an  enterprise  process  to  apply 
systems  engineering  discipkne  to  the  deci¬ 
sions  that  need  to  be  made  to  make  the  GIG 
a  reakty.  The  product  of  the  enterprise 
approach  is  a  GTF,  a  new  approach  to  GIG 
pokeies  and  a  set  of  processes  for  compk¬ 
ance  to  the  GTF. 

Whke  the  GTF  is  stkl  an  evolving  effort, 
the  requirements  in  the  GTF  have  been 
flowed  into  program  requirements  docu¬ 
ments,  ensuring  more  robust  interoperabkity 


and  performance  as  those  programs  come 
onkne  as  part  of  the  GIG.  The  approach  we 
are  putting  in  place  wik  akow  us  to  bukd, 
populate,  operate  and  protect  the  GIG  to 
meet  the  chakenges  of  today’s  worlds 
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Notes 

1 .  Some  portions  of  the  GTF  are  not  pub¬ 
licly  released. 

2.  <wwwjcs.mil/j6/netcentric.html>. 

3.  DOORS  is  an  acronym  for  Dynamic 
Object-Oriented  Requirements  System  (a 
Quality  Systems  and  Software,  Inc., 
Quality  Systems  and  Software  database 
management  system). 
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